IN THE DRAWINGS: 

The attached Replacement Sheet includes amendments to Fig. 2 and replaces 
the original sheet including Fig. 2. Fig. 2 has been amended to include examples of 
subprogram component 210. The added examples include "210 TRACKING 
SUBPROGRAM," "210 GENERATING SUBPROGRAM," and "210 CHANGING 
SUBPROGRAM." Support for these amendments may be found in at least paragraph 34 of 
the specification. 

Attachments: Replacement Sheet 
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REMARKS 

This application has been reviewed in light of the Office Action dated 
October 9, 2007. Claims 1-14 are presented for examination, with Claims 1 , 6, 9 and 14 
being in independent form. Claims 1-14 have been amended. Favorable consideration is 
requested. 

Submitted herewith is a Replacement Sheet that includes amendments to 
Fig. 2. Fig. 2 has been amended to include examples of subprogram component 210. The 
added examples include "210 TRACKING SUBPROGRAM," "210 GENERATING 
SUBPROGRAM," and "210 CHANGING SUBPROGRAM." Applicant submits that the 
amendments to Fig. 2 add no new matter to the original disclosure, and support for the 
amendments may be found in the specification at, for example, paragraph 34. Approval of 
the amended drawing is respectfully requested. Applicant also notes that although the 
specific claim language of each claim may not be present in the figures, each feature of the 
claimed invention is illustrated in the figures through the use of the exemplar}' figure 
elements described throughout the specification. It is believed that the objection to the 
drawings has been obviated and its withdrawal is therefore respectfully requested. 

Claims 5 and 13 were rejected under 35 U.S.C. § 1 12, first paragraph, as 

failing to comply with the written description requirement. On page 4, the Office Action 

states the following rationale for the written description rejection: 

The addition, division, multiplication, recompilation, 
recoding, and removal of a component are not adequately 
described in the applicant's specification. The examiner 
could only locate [0023] of the specification as being related 
to the claims and [0023] fails to elaborate on the meaning of 
such actions on a component. Therefore, the claims cannot 
be said to be described well enough in the applicant's 
specification to show possession of the claimed invention. 



Applicant respectfully disagrees. 

The plain meaning of the terms adding, dividing, multiplying, recompiling, 
recoding, and removing were widely known in the art at the time of filing. Applicant fails 
to see how one skilled in the art would need any further description to understand that 
Applicant was in possession of applying these basic concepts in the art to components in 
the context of Applicant's claimed invention. "To satisfy the written description 
requirement, an applicant must convey with reasonable clarity to those skilled in the art 
that, as of the filing date sought, he or she was in possession of the invention, and that the 
invention, in that context, is whatever is now claimed," (emphasis added) MPEP § 2163.02. 
Read with this standard in mind, a person skilled in the art would understand the concept of 
adding a component to a system , for instance. Should this rejection be maintained then 
Applicant respectfully requests further guidance as to the rationale relied on by the Office. 

Claims 5 and 13 were rejected under 35 U.S.C. § 1 12, first paragraph, as 

failing to comply with the enablement requirement. On page 4, the Office Action states the 

following rationale for the enablement rejection: 

The addition, division, multiplication, recompilation, 
recoding, and removal of a component are not adequately 
described in the applicant's specification. The examiner 
could only locate [0023] of the specification as being related 
to the claims and [0023] fails to elaborate on the meaning of 
such actions on a component. Therefore, since the meaning 
of actions such as multiplying or dividing a component that 
may be hardware (see [0017] of the applicant's specification) 
are unclear, the claimed subject matter cannot be enabled due 
to the vague and indefinite description of the subject matter 
in the applicant's specification. 

Applicant respectfully disagrees. 
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The courts have long established the standard for determining whether the 
specification meets the 35 U.S.C. § 1 12, first paragraph, enablement requirement, widely 
known as the Wands factors. See MPEP § 2164.01. These factors include: (A) The breadth 
of the claims, (B) The nature of the invention, (C) The state of the prior art, (D) The level 
of one of ordinary skill, (E) The level of predictability in the art, (F) The amount of 
direction provided by the Inventor, (G) The existence of working examples, and (H) The 
quantity of experimentation needed to make or use the invention based on the content of 
the disclosure. See MPEP § 2164.01(a) and In re Wands, 858 F.2d 731, 737 (Fed. Cir. 
1988). Applicant respectfully submits that the Office Action is completely lacking of any 
such analysis. Accordingly, Applicant respectfully requests withdrawal of this rejection. 

Furthermore, Applicant respectfully disagrees with the Office Action's 
characterization of the disclosure. The Office Action states that "the meaning of actions 
such as multiplying or dividing a component that may be hardware (see [0017] of the 
applicant's specification) are unclear," (See Office Action page 4). Whether a component 
is hardware as opposed to software (or a combination of hardware and software) does not 
change the meaning of a multiplication or division action on a component. Applicant 
submits that one skilled in the art would clearly understand that when a hardware 
component is employed in the context of Applicant's disclosure the functionality or 
elements within a component are multiplied or divided, either literally and/or logically as 
appropriate. For instance, inter alia, a hardware storage component could be multiplied by 
adding an additional component with some amount of storage to the system, reallocating 
memory in the system, or by simply adding storage to the component being multiplied. 
Applicant maintains that one skilled in the art would clearly understand the concept of 
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adding, dividing, multiplying, recompiling, recoding, and removing components in the 
context of the invention and would certainly be able to do so in view of Applicant's 
disclosure. 

Claims 1-14 were rejected under 35 U.S.C. § 1 12, second paragraph, as 
being indefinite. Applicant has carefully reviewed and amended Claims 1-14, as deemed 
necessary, to ensure that they conform fully to the requirements of Section 1 1 2, second 
paragraph, with special attention to the points raised in section 7-10 of the Office Action. It 
is believed that the rejection under Section 1 12, second paragraph, has been obviated, and 
its withdrawal is therefore respectfully requested. 

Without conceding the propriety of this rejection, Claims 1-7, 9-12, and 14 
have been amended to remove the term "may," and Claims 2-3, 8, 10, and 12 have been 
amended to remove the recitation "configured to be automatic and manual." 

Additionally, with regard to Claims 5 and 13, on page 5 the Office Action 
states "it is unclear how a component may be divided, [or] multiplied . . . [t]he meaning of 
multiplying a hardware component, for example, is unclear." Applicant respectfully 
disagrees. The fact that a component is hardware as opposed to software (or a combination 
of hardware and software) does not change the meaning of a multiplication or division 
action on a component. One of ordinary skill in the art would clearly understand that when 
a hardware component is employed in the context of Applicant's disclosure the 
functionality or elements within a component are multiplied or divided, either literally 
and/or logically as appropriate. For instance, inter alia, a hardware storage component 
could be multiplied by adding an additional component with some amount of storage to the 
system, reallocating memory in the system, or by simply adding storage to the component 
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being multiplied. Applicant maintains that one of ordinary skill in the art would clearly 
understand the concept of adding, dividing, multiplying, recompiling, recoding, and 
removing components in the context of the invention. 

The Office Action rejected Claims 1-14 under 35 U.S.C. § 102(a) and § 
102(e) as being anticipated by U.S. Patent Application Publication No. 2003/0055951 
(Chemali); rejected Claims 1-7 and 9-14 under 35 U.S.C. § 102(b) as being anticipated by 
U.S. Patent No. 6,219,676 (Reiner); and rejected Claims 1-14 under 35 U.S.C. § 102(e) as 
being anticipated by U.S. Patent Application Publication No. 2003/0172152 (Vaver). 
Applicant respectfully traverses these rejections and submits that amended independent 
Claims 1, 6, 9, and 14, together with the claims dependent therefrom, are patentably distinct 
from the cited art for at least the following reasons. 

Amended independent Claim 1 recites, in part, " detecting a failing 
component[,] . . . generating a problem ticket[,] . . . determining an owning group of the 
failing componentf,] . . . routing the problem ticket to the owning group; . . . tracking repair 
status information^] . . . and comparing the repair status information to a pre-established 
service level agreement specifying a level of service expected for repair of the failing 
component by the owning group ," (emphasis added). 

As best understood by Applicant, Chemali monitors "software applications 
running on a network, provide [s] realtime access to the [monitoring] data, [provides] 
realtime warnings and/or instructions from the evaluation of such data, and stor[es] such 
data for later evaluation," (See Chemali Abstract and paragraphs 81-82). Chemali does not 
appear to provide any tracking of repair status information, let alone " comparing the repair 
status information to a pre-established service level agreement specifying a level of service 
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expected for repair of the failing component by the owning group," as recited by Claim 1 
(emphasis added). 

Accordingly, Applicant submits that Claim 1 is not anticipated by Chemali, 
and respectfully requests withdrawal of the rejection under 35 U.S.C. § 102(a) and § 102(e). 

As best understood by Applicant, Reiner is concerned with cache coherency. 
In particular, Reiner attempts to address the cache coherency problems associated with 
dredging and web crawling by "providing] a method for the origin web server to 
intelligently communicate [a] list of changed content." See Reiner Col. 4, lines 33-49 and 
Col. 5, lines 11-19. Reiner does not appear to provide any tracking of repair status 
information, let alone " comparing the repair status information to a pre-established service 
level agreement specifying a level of service expected for repair of the failing component by 
the owning group," as recited by Claim 1 (emphasis added). 

Accordingly, Applicant submits that Claim 1 is not anticipated by Reiner, 
and respectfully requests withdrawal of the rejection under 35 U.S.C. § 102(b). 

Vaver "provides a system for . . . collecting and analyzing module-level 
service history data." See Vaver paragraph 30. Vaver 's collected service history data 
includes "when a module was manufactured; when it was received by the customer; when it 
was placed into service; when it may have been repaired in the field; when it may have been 
returned to the manufacturer for repair; when it may have been returned by the 
manufacturer; when new software or hardware modification may have been made to the 
module; the condition under which the module operated; the demand placed on the module; 
module testing . . .; when it may have been placed in or removed from inventory; and when 
it may have been relocated within the network." See Vaver paragraph 29. Vaver uses the 
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collected service history data to "better evaluate and predict the reliability of the network 
. . . , verify module reliability performance, and identify modules with chronic problems." 
See Vaver paragraph 30. 

As best understood by Applicant, Vaver, at the very least, fails to "detect[] a 
failing component ...[,] generate] a problem ticket in response to the detecting ...[,] 
determin[e] an owning group of the failing component and route[] the problem ticket to the 
owning group," as recited by Claim 1 . Furthermore, Vaver does not " comparfe] the repair 
status information to a pre-established service level agreement specifying a level of service 
expected for repair of the failing component by the owning group," as recited by Claim 1 
(emphasis added). 

Accordingly, Applicant submits that Claim 1 is not anticipated by Vaver, and 
respectfully requests withdrawal of the rejection under 35 U.S.C. § 102(e). 

Independent Claims 6, 9, and 14 include features similar to those discussed 
above with respect to Claim 1 and are believed to be patentable for at least the same reasons 
as discussed above with respect to Claim 1 . 

The other rejected claims in this application depend from one or another of 
the independent claims discussed above and, therefore, are submitted to be patentable over 
Chemali, Reiner, and Vaver for at least the same reasons. Because each dependent claim 
also is deemed to define an additional aspect of the invention, individual consideration of 
the patentability of each claim on its own merits is respectfully requested. 

In view of the foregoing amendments and remarks, Applicant respectfully 
requests favorable reconsideration and early passage to issue of the present application. 
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Applicant's undersigned attorney may be reached in our New York office by 
telephone at (212) 218-2100. All correspondence should continue to be directed to our 
below listed address. 

Respectfully submitted, 



/Jonathan Berschadsky/ 
Jonathan Berschadsky 
Attorney for Applicant 
Registration No. 46,551 



FITZPATRICK, CELLA, HARPER & SCINTO 
30 Rockefeller Plaza 
New York, New York 10112-3801 
Facsimile: (212)218-2200 
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